A challenge-response method and associated computing device

ABSTRACT

There is described a challenge-response method for a computing device. The method comprises steps of: (a) receiving challenge data at a secured module of the computing device, the challenge data comprising image content encrypted using an encryption key, and the image content including a nonce; (b) the secured module recovering the image content through decryption using one or more keys associated with the encryption key; (c) the secured module of the computing device outputting the recovered image content; (d) capturing the image content as output by the secured module; (e) processing the captured image content so as to obtain the nonce; and (f) providing the nonce as a response. There is also described a computing device arranged to carry out the challenge-response method, a computer program for causing a processor to carry out the challenge-response method, and a computer readable medium storing such a computer program.

FIELD OF THE INVENTION

The present invention relates to a challenge-response method for aclient device, and a computing device for implementing achallenge-response method. The challenge-response method of the presentinvention may be used in node locking (i.e. hardware anchoring)applications for computing devices.

BACKGROUND OF THE INVENTION

Application software, also known as an application or an app, iscomputer software designed to help the user to perform specific tasks.Examples include enterprise software, accounting software, officesuites, graphics software and media players. In recent years, theabbreviation “app” has specifically come to mean application softwarewritten for mobile devices. Application software applies the power of aparticular computing platform or system software to a particularpurpose. In other words, applications make use of the operation systemof a computing device to gain access to the hardware resources.Applications also require access to a graphics environment forinteraction with the end user. These software applications (often callednative applications) use a hardware execution engine such as a CentralProcessing Unit (CPU). An application's dependency upon existingresources in a specific computing device means that the softwareprovider may need to provide different versions of the application forexecution on different device platforms. A virtual machine executionmodel enables a software provider to distribute a single application forexecution on multiple different device platforms. Scripting languages incombination with a graphics environment are an alternative for a virtualmachine execution model, providing similar multi-platform benefits. Thisapproach has been adopted for web applications and in the HTML-5 W3Crecommendation.

Many applications require the software to be limited to a single enduser computing device (or client device). This can be achieved by makingthe execution of the software application dependent on a hardwarefunction that is specific to a single end user device.

So-called “node locking” (or “hardware anchoring”) technologies providea software application with a hardware dependent function forintegration into its execution path (see, for example EP2506174 andEP2506175). This provides a mechanism to lock the execution of theapplication to a specific end user device. The node locking functionalso enables an application to generate a message demonstrating that theapplication is operating on a particular end user device. This can beused for authentication purposes. These node locking applicationsdescribe a challenge-response function that is specific for a particularhardware circuit. A challenge-response methodology generally relies on asecret in a hardware device. Knowledge of the secret enables thegeneration of challenge-response pairs which enable an application toverify that the application is executing on the intended platform.EP2506174 and EP2506175, as referenced above, describe systems andmethods for using a node locking function (a challenge-responsefunction) in combination with secured software applications.

Node locking technologies for software applications require theavailability of a function that is specific to a particular end userdevice. EP2506175 achieves this by leveraging a specific function of astandard Subscriber Identity Module (SIM), e.g. in a mobile telephone.As the Operating System generally does not expose the SIM functionalityto applications executing on the device, the SIM locking mechanism ofEP2506175 requires modifications to the Operating System of the device.Thus, this challenge-response solution is undesirable in somecircumstances. EP2506174 requires specific hardware features in adevice, which makes this challenge-response solution unsuitable for usewith an existing device infrastructure.

Even if node locking techniques are available to local applications, webbased applications (e.g. based on HTML5) that operate in a browser, donot have access to such node locking facilities since the browserApplication Programming Interface (API) does not expose suchfunctions/facilities to the web applications.

Digital Rights Management (DRM) technologies are well known forcontrolling access to protected content files. A protected content filecomprises an encrypted content part and a usage rules part. The clientDRM system first processes the usage rules to generate a contentdecryption key that is used to decrypt the content part. Note that theusage rules part typically includes encrypted elements. The DRMimplementation in the end user device is implemented in a tamperresistant way, in order to defend against attacks against theimplementation.

DRM Systems are generally used by movie and music rights holders inorder to protect their video and audio content against unauthoriseddistribution. There are wide ranges of DRM systems that have beenintegrated for use in different end user devices (such as tablets, musicplayers, mobile phones, game consoles, and even PCs). These DRM systemsare typically implemented in a tamper resistant manner, making itdifficult for an attacker to obtain the sensitive information needed tostrip the DRM protection or to emulate the DRM client implementation.

Many end user devices (especially mobile smart phones) use Android as anoperating system. This open source operating system allows easymodifications by end users, which could potentially lead to significantproblems with unauthorised distribution of content. The deployment ofembedded hardware DRM implementations enables content distribution tosuch platforms whilst at the same time protecting against unauthoriseddistribution. For example, the Galaxy S3 mobile smart phone contains ahardware-assisted and very robust implementation of a DRM client. Theimplementation details of the DRM client, such as the hardware circuitsused, the robustness criteria and the secure storage for keys, areproprietary to the various hardware providers and/or the DRM systemproviders.

PCT/CN2013/073241 describes a challenge-response method for a clientdevice (i.e. an end user device). In particular, PCT/CN2013/073241relates to a DRM implementation of a challenge-response node lockingfunction in a client device. The “challenge” is DRM protected contentwhich includes a nonce. A client device is able to use its own DRMsystem to extract the nonce from the challenge so as to provide thenonce as a response. The challenge data could be any content encryptedusing an encryption key, the content including a nonce. However, in aspecific implementation described below with reference to FIGS. 1 and 2,the challenge data is DRM protected audio content (e.g. a DRM protectedaudio file, or streamed DRM protected audio content).

The system 10 of FIG. 1 includes a random number generator 12, an errorprotection module 14, an audio data insertion module 16 and a securedDRM module 18. The random number generator 12 (which may be apseudo-random number generator) is operable (or arranged) to generate anonce. It should be noted that, for some applications, the nonce maycontain non-random information. The error protection module 14 is anoptional element of the system and is operable to encode the nonce withan error correcting code (ECC) in order to protect against datadistortions in the nonce recovery process. In other words, the errorprotection module 14 is used to add redundancy to the nonce such thatthe nonce may be recovered by the client device even in cases ofincomplete data transmission, for example.

Audio content (e.g. an audio file) and the ECC protected nonce areprovided as inputs to the audio data insertion module 16. The audio datainsertion module 16 is operable to insert the ECC protected nonce intothe audio content. There are a number of ways in which the ECC protectednonce may be embedded into the audio content. The ECC protected noncemay be added as an audio watermark. Alternatively, the ECC protectednonce is included in the content using a modulation encoding technique.For example, the ECC protected nonce may be encoded/embedded using audiofrequency-shift keying (AFSK) or similar modulation encoding formats.Embedding the ECC protected nonce as an audio watermark produces a morepleasant audio output than embedding using AFSK or the like, but mayneed a longer audio fragment to embed the ECC protected nonce. Theoutput of the audio data insertion module 16 is plaintext/cleartext(i.e. non-encrypted) audio content (i.e. a plaintext audio file).

The secured DRM module 18 is operable to generate a DRM protectedversion of the audio content for a particular client device having aparticular “DRM client ID”. In fact, the “DRM client ID” is associatedwith a secured DRM module of the particular client device. The securedDRM module 18 of FIG. 1 is operable to process the plaintext audiocontent using the DRM client ID so as to generate a DRM protectedversion of the audio content that is suitable for playback on theidentified client device. The secured DRM module 18 achieves this usingencryption based on one or more encryption keys for the identifiedclient device (i.e. keys associated with the secured DRM module of theclient device). The encryption keys and encryption algorithms are knownto the DRM system only. For example, the encryption keys may be knownonly to the secured DRM module 18, and the corresponding decryption keysmay be known only to the secured DRM module of the particular clientdevice. There are many cryptographic techniques suitable for use in sucha DRM system. The DRM protected audio content 20 is output by thesecured DRM module 18.

FIG. 2 schematically illustrates a client device 30 (e.g. a mobile phoneor a tablet computer) for implementing the challenge-responsemethodology of PCT/CN2013/073241. The client device 30 includes an inputmodule 32, a secured DRM module 34, an audio decoder 36, a speaker 38, amicrophone 40, an audio recorder 42, a processor 44, and an outputmodule 48. Together, these elements of the client device 30 perform thenode locking function (schematically shown by the dashed line 52 in FIG.2).

The DRM protected audio content 20 output by the secured DRM module 18of FIG. 1 forms the “challenge” (or challenge data). The input module 32is operable to receive the challenge data 20 and to pass it to thesecured DRM module 34 of the client device 30. For example, the inputmodule 32 may send the challenge data with a rendering request to thesecured DRM module 34. A secured DRM module API (not shown) may be usedto activate the secured DRM module 34.

The secured DRM module 34 is operable to decrypt the challenge data 20using a decryption key of the secured DRM module 34. Specifically, thesecured DRM module parses the DRM encoded usage rules associated withthe DRM protected audio content 20, and then decrypts the DRM protectedaudio content 20 in accordance with these rules. The decrypted audiocontent is transferred to the audio decoder 36 using a secured datachannel.

The audio decoder 36 produces an audible output using the speaker 38 ofthe client device 30. Thus, the secured DRM module effectively outputsan audible version of the audio content by means of the audio decoder 36and the speaker 38.

The microphone 40 of the client device 30 is operable to receive theaudible version of the audio content output by the speaker 38. The audiorecorder 42 is operable to record the sound captured by the microphone40 so as to provide a recording of the audio content. Such a recordingof the audio content will be imperfect such that the recording is amodified version of the original audio content (as output by the audiodecoder 36 and the speaker 38). For example, the quality of the speaker38 and the microphone 40 will affect the recording (particularly incertain frequency bands). The recording will also capture environmentalnoise. Thus, the audible version of the audio content received by themicrophone 40 (and recorded by the audio recorder 42) will generally beslightly different from the audible version of the audio content outputby the speaker 38.

The processor 44 is operable to process the recording to obtain thenonce. The processor includes an audio data extraction module 45 and anerror correction module 46. The audio data extraction module 45 isoperable to access the recording of the audio content made by the audiorecorder 42. The audio data extraction module 45 is further operable torecover the ECC protected nonce from the recording using signalprocessing techniques. In other words, the audio data extraction module45 is operable to use signal processing techniques to extract the noncefrom the version of the audio content received by the microphone 40. Thesignal processing techniques used by the audio data extraction module 45will depend on the way in which the nonce has been included in the audiocontent (e.g. as an audio watermark or using a modulation encodingtechnique).

Thus, FIG. 2 schematically illustrates the arrangement ofPCT/CN2013/073241 in which the decrypted content is obtained bycapturing an analogue output (i.e. by recording the playback of an audiofile) and processing the captured analogue output of the content toextract an embedded data signal.

Having extracted the ECC protected nonce from the audio content, theaudio data extraction module 45 passes the ECC protected nonce to theoptional error correction module 46. The error correction module 46 isoperable to decode the ECC protected nonce to provide the originalnonce. The output module 48 is operable to receive the nonce from theerror correction module 46 of the processor 44 and to provide the nonceas an output of the node locking function 52. Hence, the nonce may beconsidered as the “response”.

Thus, the DRM protected audio content 20 is used in the client device 30as a challenge input to a node locking function 52 in order to obtain aresponse 50. The response 50 should be equal to the nonce (see above)and will only be obtainable by the particular client device 30containing the particular secured DRM module 34 having the relevantdecryption keys. The decryption key used may be unique to (i.e. knownonly to) the particular secured DRM module 34 such that all other clientsecured DRM modules are unable to decrypt the challenge data 20. Inother cases, the decryption key used may be unique to (i.e. known onlyto) a group of client secured DRM modules such that only secured DRMmodules in the group are able to decrypt the challenge data 20 andsecured DRM modules not in the group are unable to decrypt the challengedata 20.

In the challenge-response methodology of PCT/CN2013/073241, anapplication issues DRM protected content that contains the challenge.The protected content can only be rendered on a specific computingplatform. The challenge-response methodology of PCT/CN2013/073241thereby enables a secured application to prevent clones from executingon different computing platforms (e.g. different client devices).

SUMMARY OF THE INVENTION

The present invention provides an alternative node locking(challenge-response) function for existing devices that is accessible toapplications, virtual machine applications, and web applications(scripted applications).

According to a first aspect of the present invention, there is provideda challenge-response method for a computing device. The method comprisessteps of: (a) receiving challenge data at a secured module of thecomputing device, the challenge data comprising image content encryptedusing an encryption key, and the image content including a nonce; (b)the secured module recovering the image content through decryption usingone or more keys associated with the encryption key; (c) the securedmodule of the computing device outputting the recovered image content;(d) capturing the image content as output by the secured module; (e)processing the captured image content so as to obtain the nonce; and (f)providing the nonce as a response.

Advantageously, the challenge data further comprises a rights objectincluding usage rules relating to the image content, and the securedmodule is operable to output the recovered image content in accordancewith the usage rules.

Advantageously, the challenge data further comprises an encryptedversion of at least one of the one or more keys associated with theencryption key, and the method further comprises the secured modulerecovering said at least one key through decryption. Moreadvantageously, the encrypted version of said at least one key isprovided in the rights object.

In one embodiment, the challenge-response method further comprisesreceiving the challenge data from another computing device. For example,the challenge data may be received from a server.

In another embodiment, the challenge-response method further comprisesusing secured software on the computing device to generate the challengedata by encrypting the image content using the encryption key.

In yet another embodiment, the challenge-response method furthercomprises using secured software on the computing device to generate theimage content based on the nonce. In one example, the image content isgenerated by including the nonce in pre-existing image content (e.g. thenonce may be provided as a digital watermark on a pre-existing image).In another example, the image content may be generated by converting thenonce into an image (i.e. direct image content generation from thenonce).

Advantageously, the challenge data comprises video content includingsaid image content.

Advantageously, the challenge-response method further comprisesrendering the image content as output by the secured module. Moreadvantageously, the rendering is performed using a media playerapplication on the computing device. In one embodiment, the renderingcomprises rendering such that the image content is not observable to anend-user of the computing device.

Advantageously, the capturing comprises screen scraping or datascraping.

Advantageously, the capturing comprises directly accessing the imagecontent as output by the secured module.

According to a second aspect of the present invention, there is provideda computing device arranged to carry out the challenge-response methodof the first aspect.

According to a third aspect of the present invention, there is provideda computer program which, when executed by a processor, causes theprocessor to carry out the challenge-response method of the firstaspect.

According to a fourth aspect of the present invention, there is provideda computer readable medium storing a computer program according to thethird aspect.

Other preferred features of the present invention are set out in theappended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described by way ofexample with reference to the accompanying drawings in which:

FIG. 1 schematically illustrates a system for generating DRM protectedaudio content to form a challenge in the challenge-response method ofPCT/CN2013/073241;

FIG. 2 schematically illustrates a client device for implementing thechallenge-response method of PCT/CN2013/073241;

FIG. 3 schematically illustrates a system for generating DRM protectedvideo content to form a challenge in the challenge-response method ofthe present invention;

FIG. 3A schematically illustrates an exemplary secured DRM module forgenerating DRM protected video content for use in the challenge-responsemethod of the present invention;

FIG. 4 schematically illustrates a computing device for implementing thechallenge-response method of the present invention; and

FIG. 5 schematically illustrates a computing device for implementing alocal challenge-response method of the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

In the description that follows and in the figures, certain embodimentsof the invention are described. However, it will be appreciated that theinvention is not limited to the embodiments that are described and thatsome embodiments may not include all of the features that are describedbelow. It will be evident, however, that various modifications andchanges may be made herein without departing from the broader spirit andscope of the invention as set forth in the appended claims.

Video Content Embodiment

As compared to the audio node locking of PCT/CN2013/073241 (as describedabove with reference to FIGS. 1 and 2), the present invention relates toimage-based node locking. A preferred embodiment relates to video-basednode locking, as described below with reference to FIGS. 3 and 4.

A system 100 for the generation of the DRM protected video content isshown schematically in FIG. 3. The system 100 includes a nonce generator112, an error protection module 114, a content data insertion module 116and a secured DRM module 118. The system 100 may be a computer server orother computing device.

The nonce generator 112 is operable (or arranged) to generate a nonce.The nonce generator may comprise a random number generator and/or apseudo-random number generator. It should be noted that, for someapplications, the nonce may contain non-random information.

The error protection module 114 is operable to encode the nonce with anerror correcting code (ECC) in order to protect against data distortionsin the nonce recovery process. In other words, the error protectionmodule 114 is used to add redundancy to the nonce such that the noncemay be recovered by a client (i.e. end user) computing device even incases of incomplete data transmission (i.e. incomplete data recovery),for example. Whilst it is advantageous to add error protection to thenonce, it is not essential. Thus, the error protection module 114 is anoptional element of the system.

Video content (e.g. a video file) 115 and the ECC protected nonce areprovided as inputs to the content data insertion module 116. (Of course,it will be understood that if the error protection module 114 isomitted, then the nonce itself is provided as an input to the contentdata insertion module 116, rather than inputting the ECC protectednonce.) The content data insertion module 116 is operable to insert theECC protected nonce into the video content 115. There are a number ofways in which the ECC protected nonce may be embedded into the videocontent 115. In one embodiment, the ECC protected nonce may be added asan image watermark or a video watermark. Alternatively, the ECCprotected nonce is included in the video content 115 using anotherencoding technique. For example, a fairly simple method is to adapt someencoding parameters (DCT coefficients, motion vectors, etc.) to embedthe ECC protected nonce into the video content 115. The output of thecontent data insertion module 116 is plaintext/cleartext (i.e.non-encrypted) video content (i.e. a plaintext video file).

The secured DRM module 118 is operable to generate a DRM protectedversion of the video content for a particular computing device (clientdevice) having a particular “DRM client ID”. In fact, the “DRM clientID” is associated with a secured DRM module of the particular computingdevice. The secured DRM module 118 of FIG. 3 is operable to process theplaintext video content using the DRM client ID so as to generate a DRMprotected version of the video content that is suitable for playback onthe identified computing device. The secured DRM module 118 achievesthis by encrypting the video content using one or more contentencryption keys (CEKs). When using a symmetric encryption cipher, thedecryption key(s) (which will be used by the identified client computingdevice to decrypt the encrypted video content) are identical to theencryption key(s). In other words, the decryption key(s) are the CEK(s).In this symmetric case, it is also necessary to provide the CEK(s) (orone or more keys associated with the CEKs) to the identified clientcomputing device. This may be done by including the CEK(s) in encryptedform in a rights object which is packaged with the encrypted videocontent by means of the secured DRM module 118. Further details areprovided below. When using an asymmetric encryption cipher, thedecryption key(s) are not the same as the encryption key(s), but areassociated with the encryption key(s) (i.e. the decryption key(s) arekey(s) associated with the CEK(s)). For example, the encryption keycould be a public key associated with the client computing device andits DRM client ID, and the decryption key could be the client computingdevice's corresponding private key. The encryption cipher/algorithm maybe a known (standard) cryptographic function such as DES or AES. Atleast some of the CEK(s) (and associated decryption key(s) for anasymmetric cipher) will be known only to the DRM system (i.e. known onlyto the secured DRM module 118 and/or the corresponding DRM module in theclient computing device which will be used for decryption of thecontent). It will be understood that there are many cryptographictechniques suitable for use in such a DRM system, and these will not befurther described here.

Advantageously, the secured DRM module 118 is further operable topackage the encrypted video content with an associated rights object 219so as to form the DRM protected video content 120, as illustratedschematically in FIG. 3A. The secured DRM module 118 includes anencryption module and a content packager or multiplexer 223.Furthermore, the secured DRM module 118 has access to the DRM client IDof the particular client computing device for which the secured DRMmodule 118 is operable to provide DRM protected content 120. In oneembodiment, the secured DRM module 118 contains a database where anumber of DRM client IDs and associated keys are stored. In this case,the secured DRM module 118 may generate a rights object 219 for theparticular client computing device by accessing the database so as toobtain the DRM client ID and associated usage rules and CEK(s) that areneeded to generate the rights object 219.

The video content including the nonce is input into the encryptionmodule 217 of the secured DRM module 118, and is encrypted using theCEK. The encrypted video content is then output by the encryption module217 and packaged with the associated rights object 219 by the contentpackager 223 of the secured DRM module 118. The content 120 output bythe secured DRM module 118 then includes both the encrypted videocontent and the rights object 219. Data within the rights object 219 mayor may not be encrypted. The rights object 219 is further describedbelow.

The rights object 219 may include data defining how the encrypted videocontent is allowed to be used, once decrypted. In particular, the rightsobject 219 may be used to configure access rights to the decrypted videocontent. Importantly, the rights object 219 can be configured to allowscreen scraping (or data scraping) of the decrypted content to enable adata capturing module 142 of a client computing device 130 to obtain therelevant data to provide a response (further details are provided belowwith reference to FIG. 4). The rights object 219 may include datadefining that the video content may only be accessible to particularsoftware application(s) in the client computing device, and/or may datadefining that the video content only be viewed a predetermined number oftimes, or during a particular time window, etc. Usage rules of therights object may alternatively/additionally enforce a maximum number ofcalls to the node lock function (again, see FIG. 4 and the associateddescription for further details).

The rights object 219 may also include an encrypted version of one ormore keys associated with the encryption key(s). For example, thedecryption key(s) may be provided in encrypted form as part of therights object 219. Alternatively, it is possible to provide an encryptedversion of a seed (or key) which can be used to obtain the decryptionkey(s) or similar. As mentioned above, for a symmetric encryptioncipher, this means that the rights object 219 comprises the CEK(s) (orone or more keys associated with the CEK(s)) in encrypted form. Anencrypted version of the decryption key(s) (or of one or more other keysassociated with the encryption key) may also be included for anasymmetric cipher if desired. The important factor is that only thespecified client computing device (i.e. the end user device associatedwith the DRM client ID) should be able to decrypt the encrypted content.Thus, either the decryption key(s) should be known only to thatcomputing device (as in the example above where the CEK is the publickey of the device and the decryption key is the private key of thedevice), or sufficient information should be provided to the device aspart of the rights object 219 in encrypted form such that that thatdevice alone is able to obtain the decryption key(s). For example, in asymmetric cipher example, the CEK(s) may be provided in encrypted formas part of the rights object 219 in such a way that knowledge of theprivate key or the DRM client ID of that device is required to enabledecryption of the CEK(s). The rights object 219 may further define anylimitations on usage of the decryption key(s). For example, usagelimitations might include number of times the decryption key(s) can beused, time windows during which the decryption key(s) can be used, etc.

The secured DRM module outputs the DRM protected video content 120,which includes the encrypted video content and the associated rightsobject.

FIG. 4 schematically illustrates a computing device 130 for implementingthe present challenge-response methodology. The computing device 130 maybe a client device (i.e. an end-user device) and is intended to processthe protected DRM content 120 output by the secured DRM module 118 ofFIG. 3. Exemplary computing devices 130 include mobile devices (such assmart phones or tablets), PCs, and laptops. Other computing devices 130are also envisaged.

The computing device 130 includes an input module 132, a secured DRMmodule 134, a content decoder 136, a content rendering module 138, acontent output module 140, a data capturing module 142, a processor 144,and an output module 148. Together, these elements of the computingdevice 130 perform the node locking function (schematically shown by thedashed line 152 in FIG. 4). Clearly, the computing device 130 mayinclude other modules/elements relating to other functionality of thecomputing device 130. Some modules/elements (including some of thoseshown in FIG. 4) may be shared by multiple functional blocks of thecomputing device 130. Therefore, FIG. 4 is only a schematic depiction ofsome elements of the computing device 130.

The DRM protected video content 120 output by the secured DRM module 118of FIG. 3 forms the “challenge” (or challenge data) in the presentchallenge-response methodology. The input module 132 is operable toreceive the challenge data 120 and to pass it to the secured DRM module134 of the computing device 130 such that the challenge data 120 isreceived at the secured module 134. For example, the input module 132may send the challenge data with a rendering request to the secured DRMmodule 134. A secured DRM module API (not shown) may be used to activatethe secured DRM module 134. The input module 132 may be separate fromthe secured DRM module 134 (as shown schematically in FIG. 4), or mayform part of the secured DRM module 134 such that the secured DRM module134 itself receives the challenge data 120.

The secured DRM module 134 is operable to decrypt the challenge data 120using one or more keys associated with the encryption key(s). In otherwords, the secured module 134 is able to recover the video contentthrough decryption. As mentioned above, the one or more key(s)associated with the encryption key(s) are either already known to thesecured DRM module 134 (e.g. the decryption key is the private key ofthe secured DRM module 134), or the one or more key(s) associated withthe encryption key(s) are accessible to the secured DRM module 134 basedon the rights object 219 received as part of the challenge data 120(e.g. the rights object 219 comprises an encrypted version of the one ormore key(s) associated with the encryption key(s)). Specifically, thesecured DRM module 134 parses the DRM encoded usage rules associatedwith the DRM protected video content 120, and then decrypts the DRMprotected video content 120 in accordance with these rules. In theasymmetric encryption cipher embodiment mentioned above, the decryptionkey may be the private key of the secured DRM module 134, and theencryption key may be a public key associated with the secured DRMmodule 134 which is known to the secured DRM module 118 of FIG. 3.Alternatively, in the symmetric encryption cipher embodiment mentionedabove, the decryption key is the same as the encryption key. In thiscase, the encryption key is a symmetric secret CEK shared by both thesecured DRM module 134 of the computing device and the secured DRMmodule 118 that was used to encrypt the video content to form thechallenge data 120. Having recovered the video content throughdecryption, the secured DRM module 134 outputs the recovered (i.e.decrypted) video content in accordance with any usage rules specified inthe rights object 219.

The decrypted video content is transferred to the content decoder 136.Having decoded the video content, the content rendering module 138renders the video content on the computing device 130 in some manner. Ina preferred embodiment, the content rendering module 138 is a mediaplayer application used to render the DRM protected content on thecomputing device 130. The rendered content may be output via an optionalcontent output module 140.

At least a fragment of the decrypted video content (i.e. the output ofthe secured DRM module 134) is captured by a data capturing module 142of the computing device 130 in accordance with any usage rules in therights object 219. This capture may occur before or after decoding thecontent using the content decoder 136, and before or after rendering thecontent using the content rendering module 138. Therefore, FIG. 4 showsthree separate pathways from the secured DRM module 134 to the datacapturing module 142. In each case, the data is captured by the datacapturing module 142 prior to the content being output via the contentoutput module 140. In some DRM systems, the DRM usage rules containedwithin the rights object 219 may be used to control which softwareapplications on the computing device 130 have access rights to theoutput of the secured DRM module 134. Thus, the rights object 219 may beconfigured to define which data capture pathway is used by a particularsoftware application. Which data capture pathway is used may affectwhether secured data channels are used between the secured DRM module134 and the content decoder 136, between the content decoder 136 and thecontent rendering module 138, and between the content rendering module138 and the content output module 140. A secured data channel isintended to prevent other applications from accessing the decryptedvideo content. At least one of the three data channels mentioned aboveshould be non-secured (at least for the node-locking function) so as toenable the node locking function 152 to directly intercept the decrypteddata. This may be accomplished by the rights object 219 configuring atleast one of the three data channels to be non-secured for a particularsoftware application based on the usage rules. The version of the videofragment captured by the data capturing module 142 will generally be anexact copy (i.e. an unmodified version) of the original video content120. The output of the secured DRM module 134 is usually not observableby a non-privileged software application (i.e. a software applicationoutside the DRM trusted zone of applications). However, in order toenable the node-locking functionality, the DRM usage rules of the rightsobject 219 are configured to make the output of the secured DRM module134 observable in certain circumstances. For example, the rights object219 can be used to configure the secured DRM module 134 to allow thirdparty access to the output of the secured DRM module 134. Such thirdparty access may have restrictions applied (e.g. access only byspecified non-privileged software application(s), access only a certainnumber of times, etc.) In another example, the rights object can be usedto configure the secured DRM module 134 to send a message (using acommunication channel or a shared data file) to a specifiednon-privileged software application.

In a preferred embodiment, the data capturing module 142 captures thevideo fragment by screen scraping. In other words, the data capturingmodule 142 either is a screen scraping module or at least comprises ascreen scraping module. This provides a more robust data capturemechanism than the audio capture mechanism described above withreference to FIGS. 1 and 2. Screen scraping is normally associated withthe programmatic collection of visual data from a source, instead ofparsing data as in web scraping. Some screen scraping techniques includecapturing the bitmap data from the screen of a device and running itthrough an OCR engine or, in the case of GUI applications, querying thegraphical controls by programmatically obtaining references to theirunderlying programming objects. In the present case, the computingdevice 130 may include a screen or monitor on which the content isrendered. In other words, the content output module 140 may beconsidered to be a screen. Alternatively, the protected content may berendered so as to cause the image or video fragment not to be observableto the end-user (i.e. invisible playback). For example, the imagecontent of the video fragment could be displayed in an off-screen windowor in a not visible window, and the audio content of the video fragmentcould be played back at very low volumes, on a muted speaker or on avirtual speaker. It should be noted that it is still possible to screenscrape or data scrape such invisible or muted playback of content. Ifinvisible playback is used, the node locking application can use a broadrange of data embedding techniques to embed the nonce since it is notnecessary to insert an invisible watermark.

The processor 144 is operable to access the video fragment captured bythe data capturing module 142. The processor 144 is operable to processthe video fragment captured by the data capturing module 142 to obtainthe nonce. The processor 144 is further operable to recover the ECCprotected nonce from the captured video fragment using signal processingtechniques. In other words, the processor 144 is operable to use signalprocessing techniques to extract the nonce from the video fragmentcaptured by the data capturing module 142. The signal processingtechniques used by the processor 144 will depend on the way in which thenonce has been included in the video content (e.g. as a video watermarkor using a modulation encoding technique). Such techniques will befamiliar to a person skilled in the art.

Having extracted the ECC protected nonce from the captured data, theprocessor 144 passes the ECC protected nonce to the error correctionmodule 146. The error correction module 146 is operable to decode theECC protected nonce to provide the original nonce. Like the errorprotection module 114, the error correction module 146 is an optionalelement of the system. It is not required if the nonce does not haveadded redundancy for error protection purposes.

The output module 148 is operable to receive the nonce from the errorcorrection module 146 and to provide the nonce as an output of the nodelocking function 152. Hence, the nonce may be considered as the“response” in the present challenge-response methodology.

Thus, the DRM protected video content 120 is used in the computingdevice 130 as a challenge input to a node locking function 152 in orderto obtain a response 150. The response 150 should be equal to the nonce(see above) and will only be obtainable by the particular computingdevice 130 containing the particular secured DRM module 134 having therelevant key information. Usually the key information will be unique to(i.e. known only to) the particular secured DRM module 134 such that allother client secured DRM modules are unable to decrypt the challengedata 120. In other cases, it is envisaged that the key information willbe unique to (i.e. known only to) a group of client secured DRM modulessuch that only secured DRM modules in the group are able to decrypt thechallenge data 120 and secured DRM modules not in the group are unableto decrypt the challenge data 120. However, a decryption key (or a setof keys) unique to each secured DRM module 134 is the preferredembodiment.

Whereas an analogue path is used to capture the rendered audio output ofthe secured DRM module 34 of FIG. 2, the arrangement shown in FIG. 4uses a data capturing module 142 that captures the digital output of thesecured DRM module 134 at an earlier stage of the protected contentplayback chain. This may require configuring the secured DRM module 134to disable some data protection measures, e.g. by including relevantparameters in the usage rules of the rights object 219 in the protectedDRM content 120. For example, the protected DRM content 120 may beconfigured for playback without security measures which prevent screenscraping. As described above, such configuration may be specific toparticular software application(s) executing on the computing device130.

Depending on the location at which the data is intercepted and capturedby the data capturing module 142, a different algorithm needs to be usedby the processor 144 to generate the response. In a very simple example,the video is the repetition of a single image containing a single DCTblock with the DCT coefficients encoding the nonce. The DCT coefficientsmay encode the nonce directly (i.e. without the need to insert the nonceinto pre-prepared or pre-existing video/image content 115).Alternatively, at least a few of the DCT coefficients of a pre-preparedimage/video 115 could be amended based on the nonce. In this simple DCTencoding example, the data processing by the processor 144 would include(a) calculation of a DCT of the captured data, and (b) processing theDCT coefficients to obtain the encoded nonce. Another simple variantcould involve encoding a motion vector based on the nonce. The dataprocessing by the processor 144 would then include (a) estimating themotion vector using a ‘zero’ shift image, and (b) processing the motionvector(s) to obtain the encoded nonce. There is a wide range of moresophisticated data insertion mechanisms described in the field of audioand video watermarking, as will be appreciated by a person skilled inthe art.

For the purposes of the video content example described above, it isirrelevant whether the video content includes audio content as well asimages. Therefore, the term “video” is herein intended to encompasssilent video as well as video which includes an accompanying audiosoundtrack.

In addition, it will be appreciated that the video content need notcomprise moving pictures, but could instead encompass a still image, ora video fabricated by repetition of a still image. In either case, thesame node-locking methodology may be used, but the way in which thenonce is embedded may change—for example the use of motion vectors wouldnot be appropriate for still images.

Node Locking in Software Applications

The present DRM-based challenge-response methodology may be used fornode locking in software applications. In particular, the methodologydescribed above with respect to FIGS. 3 and 4 provides a node-lockingtechnique for a software application that captures a DRM protected videofragment (i.e. the challenge) containing an identifying data pattern (ornonce), processes the captured fragment to extract the identifyingpattern (i.e. the response), and uses it in further calculations duringexecution of the software application. As the DRM protected file 120 isconfigured for a specific end-user device, the video file cannot beplayed back on other end-user devices. The hardware based implementationof the DRM client (i.e. the secured DRM module 134) thus links theidentifying pattern (or nonce) to the specific end-user device 130. Thisnode-locking function is available to native software applications. Thewidely available browser support for playback of (DRM protected) videofiles enables the invention to provide node-locking functions for webapplications.

For example, a software application (e.g. a web application or a nativeapplication) may contain some personalization data which includes theDRM protected video content 120 that is targeted for a specific end-userdevice 130. As mentioned above, the DRM protected video content 120 canbe seen as a challenge. The application presents this challenge 120 to aDRM-protected video playback module (i.e. the node locking function ofFIG. 4) and obtains the corresponding response 150 from the signalprocessing of the captured video fragment, as described above. Theapplication may have several challenges 120 stored in thepersonalization data so as to avoid replay attacks. A reply attackinvolves successfully executing the personalized application on anend-user device other than the intended end user device 130 (i.e. otherthan the device for which the application has been personalized). Thisis done by capturing the video fragment from a screen of the intendeddevice 130, and using this previously recorded video signal to provide avalid response in another end user device. Preventing replay attacks mayalso be achieved by setting appropriate usage rules (e.g. play once) inthe rights object 219 for the DRM protected video content 120.

Node Locking for Authentication

The present DRM-based challenge-response methodology may be used forauthentication of computing devices in software applications such as webapplications. In this case, the software application executing on acomputing device 130 receives the challenge 120 (i.e. the DRM protectedvideo content 120) from a remote web server 100, which is used togenerate the challenge 120. This authentication implementation may beconsidered as a series of sequential steps, as described below withreference to features shown in FIGS. 3 and 4:

-   -   1. The application (executing on the computing device 130) sends        a request for a challenge to a server 100. This request includes        the DRM identity of the computing device 130 (i.e. the request        includes DRM client ID of the secured DRM module 134 of the        computing device 130).    -   2. The server 100 generates a nonce using the nonce generator        112.    -   3. The server 100 optionally adds error protection to the nonce        using the error protection module 114.    -   4. The server 100 uses the content data insertion module 116 to        embed the (error-protected) nonce into some video content.    -   5. The server 100 uses its secured DRM module 118 to DRM protect        the video content. Alternatively, the server 100 may request an        external DRM server system to DRM protect the generated video        content. The DRM protected video content forms the challenge        120.    -   6. The server 100 then sends the challenge 120 to the web        application executing on the computing device 130, as requested        in step 1.    -   7. The application running on the computing device 130 receives        and recovers the challenge 120 through decryption (using the        computing device's input module 132 and secured DRM module 134        respectively) before decoding, rendering and outputting the DRM        protected video content (using the computing device's content        decoder 136, content rendering module 138 and content output        module 140 respectively).    -   8. The computing device 130 then uses the data capturing module        142 to capture at least a fragment of the DRM protected video        content.    -   9. Then, the computing device 130 processes the captured        fragment using the processor 44 so as to obtain the ECC        protected nonce.    -   10. The computing device 130 optionally uses the error        correction module 146 to obtain the nonce from the ECC protected        nonce. The nonce is output by the output module 148 as the        response 150.    -   11. The response 150 is returned (i.e. sent) to the server 100        to demonstrate that the application is executing on the intended        platform (i.e. on an authorized computing device 130). This        approach can be used for authentication.    -   12. The computing device 130 may use the response 150 in the        execution of the application. For example, the response 150 may        be used within the application to at least partially enable the        continued execution of the application on the end user device        130.

As described above, it is also possible to include a rights object 219in the DRM protected video content 120 for further configuration of thesecured DRM module of the computing device 130.

Local Node Locking Embodiment

As described above in relation to node locking in software applications,a number of server-generated challenges may be stored by a softwareapplication to enable node locking on the computing device 130. Suchchallenges will need to be loaded into the software application on thecomputing device 130. This loading can use a communication interface toa server 100 or a pre-packaging step during installation of the softwareapplication. This poses some constraints on the software applicationsince either a communication link has to be available, or a finitenumber of pre-packaged challenges can be used. Similarly, theauthentication implementation described above requires a communicationlink between the server 100 and the computing device 130 to enable steps1, 6 and 11 to be carried out, since each of these steps requirescommunication between the server 100 and the computing device 130.Therefore, in an alternative embodiment of the invention, a local nodelocking function is provided which executes entirely on a localcomputing device such as the computing device 130.

The way DRM systems work (when using symmetric cryptographic ciphers) isthat a content encryption key (CEK) is delivered using a rights object.The packaging of content is done using a content packager which takesthe CEK, uses it to encrypt the content, and packages the encryptedcontent with the rights object into a protected content file. Therefore,if the content packager functionality (e.g. the challenge generationfunctionality of FIG. 3) is implemented within the software applicationitself (i.e. on the computing device 130), it becomes possible to issuerandom node locking challenges. Such an embodiment is described below.

An important aspect of a node locking operation is that there should bea way to verify the response so the software application can beconfident that it is running on the intended platform (i.e. anauthorised computing device). The process to calculate the response fromthe captured data can be implemented in a non-secured piece of software.In other words, the data capturing module 142, the processor 144, theerror correction module 146 and the output module 148 of FIG. 4 can allbe implemented as non-secured software modules on the computing device130. However, in order to prevent attacks, it is necessary to implementthe challenge generation functionality of FIG. 3 using secured softwaretechniques. The challenge generation functionality uses the noncegenerator 112 for generating the nonce (which acts as the challenge inthis local node locking embodiment), the optional error protectionmodule 114 for optional error protection of the nonce, the content datainsertion module 116 for embedding the (error-protected) nonce into apiece of video content, and the secured DRM module 118 which acts as thecontent packager in this instance. In addition, any software whichconfigures the continued execution of the software application to relyon the intended response should use secured software techniques.

There are many secured software techniques known in the art. Forexample, software obfuscation and/or white-box cryptography can be usedto implement the secured software described above. Such techniques arebriefly discussed in the Annex below, and some techniques use atransformed data domain to process sensitive data in a secured manner.In particular, the original data is stored and processed as transformeddata such that it is difficult or impossible for an attacker to derivethe original data. In general, secured software is arranged so that theassociated software code has resistance against a white-box attack.

In one embodiment, a pre-packaged content sample can be included withthe software application (on the computing device 130) as transformeddata. The embedding process (using the content data insertion module116) then can take place in the transformed data domain using atransformed (and possibly error-protected) nonce. This effectively hidesthe embedding process from attackers. The transformed content with theembedded response can be passed to a white-box encryption module forencryption using white-box encryption which is configured to operate ontransformed data. The white-box encryption module is configured with afixed CEK or has a facility to load a CEK.

FIG. 5 schematically illustrates an example of a local node lockingfunction 252 which executes entirely on a local computing device such asthe computing device 130. Components in FIG. 5 that are similar to thosedepicted in FIGS. 3, 3A and 4 are depicted with the same referencenumeral as those used in FIGS. 3, 3A and 4. The computing device 130includes the nonce generator 112, the error protection module 114, thecontent data insertion module 116, the secured DRM module 118 (includinga white-box encryption module 317 (in place of the generic encryptionmodule 217) and the content packager 223, as shown schematically by thedotted line), the secured DRM module 134, the content decoder 136, thecontent rendering module 138, the content output module 140, the datacapturing module 142, the processor 144, and the output module 148.Except for the nonce generator 112, these elements of the computingdevice 130 together perform the node locking function (schematicallyshown by the dashed line 252 in FIG. 5). In an alternative embodiment,the error protection and error correction could occur outside the nodelocking function 252 if desired.

In use of the computing device of FIG. 5, consider a softwareapplication on the computing device 130 which wishes to use (i.e. call)the node-locking function 252. The software application uses the noncegenerator 112 to generate a nonce as transformed data. As describedabove, the nonce may be random, pseudo-random, or non-random. The nonceis later used to generate a “challenge”. The transformed nonce isreceived by the (optional) error protection module 114 of the nodelocking function 252 to apply error protection to the transformed nonceif required. The transformed nonce is then embedded in the pre-packagedcontent sample 115 which is included with the software application astransformed data. The embedding process (using the content datainsertion module 116) takes place in the transformed data domain usingthe transformed (and possibly error-protected) nonce. The transformedcontent with the embedded nonce is passed to the white-box encryptionmodule 317 for encryption using white-box encryption which is configuredto operate on transformed data. The white-box encryption module 317 isconfigured with a fixed CEK or has a facility to load a CEK. The securedsoftware (white-box cryptography) technology secures the CEK under thewhite-box attack scenario. The encrypted content and nonce data is thenpassed to a content packager or multiplexer 223 to package the encrypteddata together with the rights object 219 associated with usage of thecontent, thereby outputting protected DRM content 120 which acts as achallenge. The rights object 219 is described above in detail in the“Video content embodiment” section. However, it should be noted thatwhen the secured DRM module 118 (which generates the protected DRMcontent 120) is operable to execute on the client computing device 130(as in FIG. 5) rather than on the server computing device 100 (as inFIG. 3), that module 118 lacks a rights objects generation capability.Instead, it uses pre-packaged rights object(s) with suitable keys andusage rules.

The secured DRM module 134 receives the protected DRM content 120 and isoperable to recover the combined content and nonce data throughdecryption using one or more keys associated with the encryption key.Specifically, the secured DRM module 134 parses the DRM encoded usagerules in the rights object 219 packaged within the protected DRM content120, and then decrypts the encrypted video content in accordance withthese rules. Further details regarding the relevant key(s) are givenabove in the “Video content embodiment” section.

Having decrypted the combined content and nonce data, the output fromthe secured DRM module 134 is passed in turn to the content decoder 136,the content rendering module 138 and the content output module 140. Atsome point in this chain, as described above with reference to FIG. 4,the data is captured by the data capturing module 142 and passed in turnto the processor 144, the error correction module 146 and the outputmodule 148 as so as to generate the response 150. Again, this process isdescribed above with reference to FIG. 4. Of course, in this localembodiment, the response is a transformed nonce (i.e. the nonce is inthe transformed data domain).

Thus, the local node locking embodiment of FIG. 5 shows the protectedcontent playback and the steps to generate a response 150 from theplayback processing chain. In addition, FIG. 5 shows the contentprotection and DRM packaging. The content 115 and the rights object 219are associated with the secured software application 134 of thecomputing device 134. FIG. 5 does not show the steps to configure thesoftware application to verify a particular response from the protectedcontent playback. Nonetheless, this verification process has beendescribed above.

Variations

The following variations may be combined in any way, unless otherwisestated.

FIGS. 3 and 4 illustrate an embodiment in which protected DRM content120 is generated by a server system 100, and this content 120 forms achallenge to a computing device 130, which implements the subsequentnode-locking functionality locally. In contrast, FIG. 5 illustrates anembodiment in which all functions (including the content generation) areimplemented locally in the computing device 130. Secured softwaretechniques are used as necessary. Intermediate implementations are alsoenvisaged where some (but not all) of the content generation modules ofFIG. 3 are moved to the local computing device 130. For example, theerror protection module 114 and the content data insertion module 116(or the equivalent encoding module described above) could be implementedat the server 100, whilst the secured DRM module 118 for generating theDRM protected content 120 could be implemented locally in the computingdevice 130 using secured software techniques.

In alternative embodiments, there is no need to provide the videocontent 115 into which the nonce is embedded. Instead, it is possible toencode the nonce itself as an image or video file, without the need toinsert the nonce into another piece of image or video content 115. Thus,this embodiment relates to direct image or video content generationbased on the nonce. For example, the nonce may be encoded into an imageusing a barcode. An even simpler example encodes the nonce into an imageusing greyscale values where each pixel is an encoding of a byte ofdata. Thus, in this embodiment, the pre-packaged content sample 115 andthe content data insertion module 116 are replaced with an encodingmodule (not shown) for encoding the nonce into image (or video) format.In other words, the nonce is itself converted into an image using theencoding module.

It will be appreciated that the methods described have been shown asindividual steps carried out in a specific order. However, the skilledperson will appreciate that these steps may be combined or carried outin a different order whilst still achieving the desired result.

It will be appreciated that embodiments of the invention may beimplemented using a variety of different information processing systems.In particular, although the figures and the discussion thereof providean exemplary computing system and methods, these are presented merely toprovide a useful reference in discussing various aspects of theinvention. Embodiments of the invention may be carried out on anysuitable data processing device, such as a personal computer, laptop,personal digital assistant, mobile telephone, set top box, television,server computer, etc. Of course, the description of the systems andmethods has been simplified for purposes of discussion, and they arejust one of many different types of system and method that may be usedfor embodiments of the invention. It will be appreciated that theboundaries between logic blocks (e.g. the input module 132 and thesecured module 134) are merely illustrative and that alternativeembodiments may merge logic blocks or elements, or may impose analternate decomposition of functionality upon various logic blocks orelements.

It will be appreciated that the above-mentioned functionality may beimplemented as one or more corresponding modules as hardware and/orsoftware. For example, the above-mentioned functionality may beimplemented as one or more software components for execution by aprocessor of the system. Alternatively, the above-mentionedfunctionality may be implemented as hardware, such as on one or morefield-programmable-gate-arrays (FPGAs), and/or one or moreapplication-specific-integrated-circuits (ASICs), and/or one or moredigital-signal-processors (DSPs), and/or other hardware arrangements.Method steps implemented in flowcharts contained herein, or as describedabove, may each be implemented by corresponding respective modules;multiple method steps implemented in flowcharts contained herein, or asdescribed above, may together be implemented by a single module.

It will be appreciated that, insofar as embodiments of the invention areimplemented by a computer program, then a storage medium and atransmission 1 0 medium carrying the computer program form aspects ofthe invention. The computer program may have one or more programinstructions, or program code, which, when executed by a computercarries out an embodiment of the invention. The term “program,” as usedherein, may be a sequence of instructions designed for execution on acomputer system, and may include a subroutine, a function, a procedure,a module, an object method, an object implementation, an executableapplication, an applet, a servlet, source code, object code, a sharedlibrary, a dynamic linked library, and/or other sequences ofinstructions designed for execution on a computer system. The storagemedium may be a magnetic disc (such as a hard drive or a floppy disc),an optical disc (such as a CD-ROM, a DVD-ROM or a BluRay disc), or amemory (such as a ROM, a RAM, EEPROM, EPROM, Flash memory or aportable/removable memory device), etc. The transmission medium may be acommunications signal, a data broadcast, a communications link betweentwo or more computers, etc.

Annex—Software Obfuscation and White-Box Cryptography

An obfuscated item of software may store secret information (such as acryptographic key) in a protected or obfuscated manner to thereby makeit more difficult (if not impossible) for an attacker to deduce oraccess that secret information (whereas if a user device were providedwith the item of software in an unprotected form, then the operator ofthe user device might have been able to deduce or access that secretinformation).

For example, the item of software may comprise a decision (or a decisionblock or a branch point) that is based, at least in part, on one or moreitems of data to be processed by the item of software. If the item ofsoftware were provided to a user device (e.g. computing device 130) inan unprotected form, then an attacker may be able to force the item ofsoftware to execute so that a path of execution is followed afterprocessing the decision even though that path of execution were notmeant to have been followed. For example, the decision may comprisetesting whether a program variable B is TRUE or FALSE, and the item ofsoftware may be arranged so that, if the decision identifies that B isTRUE then execution path P_(T) is followed/executed whereas if thedecision identifies that B is FALSE then execution path P_(F) isfollowed/executed. In this case, the attacker could (for example byusing a debugger) force the item of software to follow path P_(F) if thedecision identified that B is TRUE and/or force the item of software tofollow path P_(T) if the decision identified that B is FALSE. Therefore,some software obfuscation techniques aim to prevent (or at least make itmore difficult) for the attacker to do this by applying one or moresoftware protection techniques to the decision within the item ofsoftware.

In another example, the item of software may comprise one or more of asecurity-related function; an access-control function; a cryptographicfunction; and a rights-management function. Such functions often involvethe use of secret data, such as one or more cryptographic keys. Theprocessing may involve using and/or operating on or with one or morecryptographic keys. If an attacker were able to identify or determinethe secret data, then a security breach has occurred and control ormanagement of data (such as audio and/or video content) that isprotected by the secret data may be circumvented. Therefore, in somesoftware obfuscation techniques aim to prevent (or at least make it moredifficult) for the attacker to identify or determine the one or morepieces of secret data by applying one or more software protectiontechniques to such functions within the item of software.

A “white-box” environment is an execution environment for an item ofsoftware in which an attacker of the item of software is assumed to havefull access to, and visibility of, the data being operated on (includingintermediate values), memory contents and execution/process flow of theitem of software. Moreover, in the white-box environment, the attackeris assumed to be able to modify the data being operated on, the memorycontents and the execution/process flow of the item of software, forexample by using a debugger—in this way, the attacker can experiment on,and try to manipulate the operation of, the item of software, with theaim of circumventing initially intended functionality and/or identifyingsecret information and/or for other purposes. Indeed, one may evenassume that the attacker is aware of the underlying algorithm beingperformed by the item of software. However, the item of software mayneed to use secret information (e.g. one or more cryptographic keys),where this information needs to remain hidden from the attacker.Similarly, it would be desirable to prevent the attacker from modifyingthe execution/control flow of the item of software, for examplepreventing the attacker forcing the item of software to take oneexecution path after a decision block instead of a legitimate executionpath. There are numerous techniques, referred to herein as “white-boxobfuscation techniques”, for transforming the item of software so thatit is resistant to white-box attacks. Examples of such white-boxobfuscation techniques can be found, in Examples of such white-boxobfuscation techniques can be found, in “White-Box Cryptography and anAES Implementation”, S. Chow et al, Selected Areas in Cryptography,9^(th) Annual International Workshop, SAC 2002, Lecture Notes inComputer Science 2595 (2003), p 250-270 and “A White-box DESImplementation for DRM Applications”, S. Chow et al, Digital RightsManagement, ACM CCS-9 Workshop, DRM 2002, Lecture Notes in ComputerScience 2696 (2003), p 1-15, the entire disclosures of which areincorporated herein by reference. Additional examples can be found inU.S. 61/055,694 and WO2009/140774, the entire disclosures of which areincorporated herein by reference. Some white-box obfuscation techniquesimplement data flow obfuscation—see, for example, U.S. Pat. No.7,350,085, U.S. Pat. No. 7,397,916, U.S. Pat. No. 6,594,761 and U.S.Pat. No. 6,842,862, the entire disclosures of which are incorporatedherein by reference. Some white-box obfuscation techniques implementcontrol flow obfuscation—see, for example, U.S. Pat. No. 6,779,114, U.S.Pat. No. 6,594,761 and U.S. Pat. No. 6,842,862 the entire disclosures ofwhich are incorporated herein by. However, it will be appreciated thatother white-box obfuscation techniques exist and that examples of themay use any white-box obfuscation techniques.

1. A challenge-response method for a computing device, the method beingimplemented by one or more processors and comprising steps of: receivingchallenge data at a secured module of the computing device, thechallenge data comprising image content encrypted using an encryptionkey, and the image content including a nonce; the secured modulerecovering the image content through decryption using one or more keysassociated with the encryption key; the secured module of the computingdevice outputting the recovered image content; capturing the imagecontent as output by the secured module; processing the captured imagecontent so as to obtain the nonce; and providing the nonce as aresponse.
 2. The challenge-response method of claim 1 wherein thechallenge data further comprises a rights object including usage rulesrelating to the image content, and the secured module is operable tooutput the recovered image content in accordance with the usage rules.3. The challenge-response method of claim 2 wherein the challenge datafurther comprises an encrypted version of at least one of the one ormore keys associated with the encryption key, and the method furthercomprises the secured module recovering said at least one key throughdecryption.
 4. The challenge-response method of claim 3 wherein theencrypted version of said at least one key is provided in the rightsobject.
 5. The challenge-response method of claim 1 further comprisingreceiving the challenge data from another computing device.
 6. Thechallenge-response method of claim 1 further comprising: using securedsoftware on the computing device to generate the challenge data byencrypting the image content using the encryption key.
 7. Thechallenge-response method of claim 6 further comprising: using securedsoftware on the computing device to generate the image content based onthe nonce.
 8. The challenge-response method of claim 7 wherein the imagecontent is generated by including the nonce in pre-existing imagecontent.
 9. The challenge-response method of claim 7 wherein the imagecontent is generated by converting the nonce into an image.
 10. Thechallenge-response method of claim 1 wherein the challenge datacomprises video content including said image content.
 11. Thechallenge-response method of claim 1 further comprising rendering theimage content as output by the secured module.
 12. Thechallenge-response method of claim 11 wherein the rendering is performedusing a media player application on the computing device.
 13. Thechallenge-response method of claim 11 wherein the rendering comprisesrendering such that the image content is not observable to an end userof the computing device.
 14. The challenge-response method of claim 1wherein the capturing comprises screen scraping or data scraping. 15.The challenge-response method of claim 1 wherein the capturing comprisesdirectly accessing the image content as output by the secured module.16. A computing device comprising a secured module and one or moreprocessors arranged to carry out a challenge-response method by:receiving challenge data at the secured module of the computing device,the challenge data comprising image content encrypted using anencryption key, and the image content including a nonce; the securedmodule recovering the image content through decryption using one or morekeys associated with the encryption key; the secured module of thecomputing device outputting the recovered image content; capturing theimage content as output by the secured module; processing the capturedimage content so as to obtain the nonce; and providing the nonce as aresponse.
 17. One or more tangible computer readable media comprisingcomputer program code which, when executed by a processor, causes theprocessor to carry out a challenge-response method for a computingdevice by: receiving challenge data at a secured module of the computingdevice, the challenge data comprising image content encrypted using anencryption key, and the image content including a nonce; the securedmodule recovering the image content through decryption using one or morekeys associated with the encryption key; the secured module of thecomputing device outputting the recovered image content; capturing theimage content as output by the secured module; processing the capturedimage content so as to obtain the nonce; and providing the nonce as aresponse.
 18. (canceled)